Hi @bix0r, good to see u're back :)

Let's please work on >= PHP 8.1

The rest are EOLed, we shouldn't really spend any efforts there, either we fully support or not fully support. Let's focus our efforts towards the future, I'm happy to have a call about this if needed.

I am going to move this PR to draft because there is some discussion on the vendor name for extensions living in github.com/php. See Composer issue.

I am going to move this PR to draft because there is some discussion on the vendor name for extensions living in github.com/php. See Composer issue.

sure

@remicollet I wonder if we should add this package to the pecl/ namespace?

I see that you have been adding some existing packages to the pecl/ namespace, and according to https://externals.io/message/128536#128614 and a comment on the linked composer issue above, it seems like that would be the way to go.

Otherwise I think that I will just go with php-solr/solr. Other option would be apache/php-solr that has been proposed to me in discussions with some core devs, but I am not sure I like that one.

@remicollet I wonder if we should add this package to the pecl/ namespace?

Your choice ;)
In this case, you need someone who already own 1 pecl package to add it in this namespace, and then give you the ownership. (I can do it).

I think "pecl" vendor is useful for extensions inherited from the community with no real author. Also for project in the php github organization (moved from git.php.net)

"apache" may be interesting for all ASF hosted projects, but if used by this extension it will be locked (like the pecl one) so probably only if really managed by the ASF.

I also think "php" or "pie" in the "project" name doesn't make sense (everything is for php on packagist).

Thank you for your input @remicollet. I really like your reasoning :)

I think "pecl" vendor is useful for extensions inherited from the community with no real author. Also for project in the php github organization (moved from git.php.net)

Since this package is not heading for major development and is in the php GH organisation, I think pecl is the best suited vendor. If we ever want to do some major refactoring or changes we could then look into moving it to its own organisation and then change the vendor.

@omars44 What do you think?

Your choice ;) In this case, you need someone who already own 1 pecl package to add it in this namespace, and then give you the ownership. (I can do it).

I will ping you if we decide to use pecl. Thank you.